I. Field of the Invention
II. Description of the Related Art
The use of code division multiple access (CDMA) modulation techniques is one of several techniques for facilitating communications in which a large number of system users are present. Other multiple access communication system techniques, such as time division multiple access (TDMA), frequency division multiple access (FDMA) and AM modulation schemes such as amplitude companded single sideband (ACSSB) are known in the art. These techniques have been standardized to facilitate interoperation between equipment manufactured by different companies. Code division multiple access communications systems have been standardized in the United States in Telecommunications Industry Association TIA/EIA/IS-95-B, entitled “MOBILE STATION-BASE STATION COMPATIBILITY STANDARD FOR DUAL-MODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEMS”, incorporated by reference herein, and hereinafter referred to as IS-95.
IS-95 was originally optimized for transmission of variable-rate voice frames. In order to support two-way voice communications, as typified in wireless phone applications, it is desirable that a communication system provide fairly constant and minimal data delay. For this reason, IS-95 systems are designed with powerful forward error correction (FEC) protocols and vocoders which are designed to respond gracefully to voice frame errors. Error control protocols which require frame retransmission procedures add unacceptable delays to voice transmission, so are not designed into the IS-95 specification.
The optimizations which make the standalone IS-95 specification ideal for voice applications make it difficult to use for packet data applications. In many non-voice applications, such as the transmission of Internet protocol (IP) data, the delay requirements of the communication system are much less stringent than in voice applications. In the Transmission Control Protocol (TCP), probably the most prevalent of protocols used in an IP network, virtually infinite transmission delays are allowed in order to guarantee error-free transmission. TCP uses retransmissions of IP datagrams, as IP packets are commonly called, to provide this transport reliability.
IP datagrams are generally too large to fit into a single IS-95 frame. Even after dividing an IP datagram into segments small enough to fit into a series of IS-95 frames, an entire series of IS-95 frames would have to be received without error for the single IP datagram to be useful to TCP. The frame error rate typical of an IS-95 system make the probability of error-free reception of all segments of a single datagram very low.
As described in IS-95, alternative service options enable the transmission of other types of data may in lieu of voice frames. The TIA/EIA/IS-707-A, entitled “DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS”, hereafter referred to as IS-707, describes procedures used in the transmission of packet data in an IS-95 system.
Radio Link Protocol (RLP) is described in TIA/EIA/IS-707-A.8, entitled “DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: RADIO LINK PROTOCOL TYPE 2”, hereinafter referred to as RLP2, and incorporated herein by reference. RLP2 incorporates an error control protocol with frame retransmission procedures over the IS-95 frame layer. RLP is of a class of error control protocols known NAK-based ARQ protocols, which are well known in the art. The IS-707 RLP, facilitates the transmission of a byte-stream, rather than a series of voice frames, through an IS-95 communication system.
Several protocol layers typically reside above the RLP layer. IP datagrams, for example, are typically converted into a Point-To-Point Protocol (PPP) byte stream before being presented as a byte stream to the RLP protocol layer. As the RLP layer ignores the protocol and framing of higher protocol layers, the stream of data transported by RLP is said to be a “featureless byte stream”.
RLP was originally designed to satisfy the requirements of sending large frames through an IS-95 channel. For example, if an IP datagram of 500 bytes were to be simply sent in IS-95 frames carrying 20 bytes each, the IP datagram would fill 25 consecutive IS-95 frames. Without some kind of error control layer, all 25 of these frames would have to be received without error in order for the IP datagram to be useful to higher protocol layers. On an IS-95 channel having a 1% frame error rate, the effective error rate of the IP datagram delivery would be (1−(0.99)25), or 22%. This is a very high error rate compared to most networks used to carry Internet Protocol traffic. RLP was designed as a link layer protocol which would decrease the error rate of IP traffic to be comparable to the error rate typical of a 10Base2 ethernet channel.
The International Telecommunications Union recently requested the submission of proposed methods for providing high rate data and high-quality speech services over wireless communication channels. A first of these proposals was issued by the Telecommunications Industry Association, entitled “The cdma2000 ITU-R RTT Candidate Submission”, and hereinafter referred to as cdma2000. A second of these proposals was issued by the European Telecommunications Standards Institute (ETSI), entitled “The ETSI UMTS Terrestrial Radio Access (UTRA) ITU-R RTT Candidate Submission”, also known as “wideband CDMA” and hereinafter referred to as W-CDMA. A third proposal was submitted by U.S. TG 8/1 entitled “The UWC-136 Candidate Submission”, hereinafter referred to as EDGE. The contents of these submissions is public record and is well known in the art.
RLP2 is optimized for use with IS-95B, in which the rate set, derived from channel capacity, used during a packet data call remains essentially fixed for the duration of the call. Based on this assumption of fixed rate sets, RLP2 is designed with the assumption that retransmitted RLP frames can be sent within a maximum of three consecutive RLP segments. The probability that one of three segments is lost, causing the loss of a retransmitted RLP frame, has been deemed acceptable by the designers of RLP2.
In cdma2000, however, the channel capacity available to a single user, and hence the maximum data rate used during a packet data call, can vary widely and rapidly. For example, during the course of a single cdma2000 call, the supplemental channel capacity used by a packet data service option may vary from 9.6 kilo-bits per second (kbps) to more than 307 kbps. In a simple extension of the RLP2, the maximum number of segments used during retransmissions could be increased as necessary to accommodate the change in data rates. Because the capacity of a call channel may diminish during a call, a full-rate frame transmitted unsuccessfully at a high rate might span 30 or more consecutive lower-rate-set cdma2000 segments. The high likelihood that one or more of those cdma2000 segments makes such a simple extension of the RLP2 largely impractical for use with cdma2000.
RLP2 has been optimized to require minimal protocol overhead space over the two IS-95 rate sets, known as Rate Set 1 (RS1) and Rate Set 2 (RS2). The RLP frame sequence numbers in RLP2 are 8 bits long, a size which is ideal for computer processing. Since the rate sets specified in cdma2000 include RS1 and RS2, it would be highly desirable for an RLP designed for cdma2000 (RLP2000) to be at least as efficient as RLP2 when used at RS1 and RS2. Because switching RLP protocols whenever the rate set changes would add complexity to RLP2000, it is desirable that a single RLP2000 protocol efficiently support RS1, RS2, and all the higher cdma2000 data rates without requiring resynchronization or substantial protocol complexity.
Another problem that arises in using RLP2 on a high-data-rate channel is transmit sequence number ambiguity. Though the sender and receiver in an RLP2 link maintain 12-bit RLP sequence numbers, all data-bearing frames carry only the least-significant 8 bits of their sequence numbers. The number of sequence-number bits contained in over-the-air RLP frames determines the number of outstanding frames that can be unambiguously tracked by the receiver of the data. The sequence number space within such a block of outstanding frames is often referred to in the art as a “sliding window.” In RLP2, each 8-bit over-the-air sequence number can be used to unambiguously identify one 12-bit sequence number, and hence one data frame, within a window of 256 consecutive sequence numbers. Any frame whose 12-bit sequence number falls outside the sliding window will have a counterpart within the sliding window whose 12-bit sequence number has the same least-significant 8 bits. The receiver of both of these data frames will be unable to tell the frames apart from each other.
In older versions of the IS-95 protocol (earlier than IS-95B), one data frame is transmitted every 20 milliseconds (50 per second), and the 8-bit RLP sequence number space spans approximately 5 seconds of consecutive data frames. On such a channel, a deep fade lasting longer than 5 seconds could cause the loss of more than 255 consecutive data frames. As a result, the 8-bit RLP sequence numbers would “wrap-around” and can cause ambiguity for new-data frames and for retransmit frames containing 8-bit shortened sequence numbers. With older IS-95 implementations, the wrap-around problem does not occur, because a 5-second fade causes the call to drop entirely. Whenever RLP performs a reset, data in the RLP byte stream is lost.
Newer protocols such as IS-95B, however, allow sending multiple frames in a single 20-millisecond period. This makes it possible to exhaust the over-the-air sequence numbers in a much shorter fade. For example, in IS-95B, which allows sending eight frames per 20-millisecond period, an 8-bit sequence number window can be exhausted in 640 milliseconds. In RLP2, which is designed for use with IS-95B, RLP performs a reset whenever 255 consecutive received frames are classified as erasures. Thus, a deep fade on an RLP2 link which lasts as little as 640 milliseconds may cause an RLP reset, along with its associated data loss.
As discussed in the aforementioned RLP2 and all existing RLP implementations, three variables are maintained at either side of an RLP protocol link. These variables are V(R), V(N) and V(S). As discussed in the RLP standards, V(R) contains the expected value of the RLP frame sequence number field in the next new traffic channel frame to be received. V(N) contains the sequence number of the next needed traffic channel frame not received in sequence. The sequence number field ‘SEQ’ in each new RLP data frame sent and in each RLP idle frame sent shall be set to V(S). Each of the variables V(R), V(N) and V(S) are the shortened (8-bit), over-the-air versions of the full (12-bit) sequence numbers L_V(R), L_V(N) and L_V(S) also maintained at either side of an RLP protocol link.
RLP is a NAK-based protocol, which means that a sender continues to send new data until it receives a NAK. Since a deep fade often causes the loss of packets in both directions of a channel, a deep fade can cause the loss of both data frames sent in one direction and the corresponding NAK frames in the other direction. The same problem can occur whether frame sequence numbers or byte sequence numbers are used, because a minimal number of bits are used in over-the-air sequence numbers in either method. A deep fade that causes the loss of a large number of sequential frames can cause sequence number wrap-around with either sequence number scheme.
Thus, a method of resolving sequence number ambiguity that is simple, efficient and does not significantly add to over-the-air sequence number overhead is highly desirable.